Synchronization of recurring records in incompatible databases

ABSTRACT

A technique for synchronizing databases in which different techniques are used for storing a recurring event. A database in which the recurring event is, for example, stored as a single recurring record can be synchronized with a database in which the same recurring event is stored as a series of individual records. The individual records are processed to form a synthetic recurring record representing the set of individual records, and synchronization decisions are based on a comparison of the synthetic record to the recurring record of the other database. Following synchronization, the synthetic record can be “fanned” back into the individual records to update the database containing individual records, and the updated recurring record can be written back to the other database. In this way, the invention avoids the problems encountered with prior methods, in which synchronization resulted in a recurring record being transformed into a series of individual records.

REFERENCE TO MICROFICHE APPENDIX

An appendix (appearing now in paper format to be replaced later inmicrofiche format) forms part of this application. The appendix, whichincludes a source code listing relating to an embodiment of theinvention, includes 691 frames on 8 microfiche.

This patent document (including the microfiche appendix) containsmaterial that is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument as it appears in the Patent and Trademark Office file orrecords, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

This invention relates to synchronizing incompatible databases.

Databases are collections of data entries which are organized, stored,and manipulated in a manner specified by applications known as databasemanagers (hereinafter also referred to as “Applications”). The manner inwhich database entries are organized in a database is known as the datastructure. There are generally two types of database managers. First aregeneral purpose database managers in which the user determines (usuallyat the outset, but subject to future revisions) what the data structureis. These Applications often have their own programming language andprovide great flexibility to the user. Second are special purposedatabase managers that are specifically designed to create and manage adatabase having a preset data structure. Examples of these specialpurpose database managers are various scheduling, diary, and contactmanager Applications for desktop and handheld computers. Databasemanagers organize the information in a database into records, with eachrecord made up of fields. Fields and records of a database may have manydifferent characteristics depending on the database manager's purposeand utility.

Databases can be said to be incompatible with one another when the datastructure of one is not the same as the data structure of another, eventhough some of the content of the records is substantially the same. Forexample, one database may store names and addresses in the followingfields: FIRST_NAME, LAST_NAME, and ADDRESS. Another database may,however, store the same information with the following structure: NAME,STREET_NO., STREET_NAME, CITY_STATE, and ZIP. Although the content ofthe records is intended to contain the same kind of information, theorganization of that information is completely different.

It is often the case that users of incompatible databases want to beable to synchronize the databases. For example, in the context ofscheduling and contact manager Applications, a person might use oneApplication on the desktop computer at work and another on his handheldcomputer or his laptop computer at home. It is desirable for many ofthese users to be able to synchronize the entries on one with entries onanother. However, the incompatibility of the two databases creates manyproblems that need to be solved for successful synchronization. The U.S.patent and copending patent application of the assignee hereof,IntelliLink Corp., of Nashua, N.H. (U.S. Pat. No. 5,392,390; U.S.application, Ser. No. 08/371,194, filed on Jan. 11, 1995, now U.S. Pat.No. 5,684,990, incorporated by reference herein) show two methods forsynchronizing incompatible databases and solving some of the problemsarising from incompatibility of databases. However, other problemsremain.

One kind of incompatibility is when one database manager uses recurringrecords. Recurring records are single records which contain informationwhich indicates that the records actually represent multiple recordssharing some common information. Many scheduling Applications, forexample, permit as a single record an event which occurs regularly overa period of time. Instances of such entries are biweekly committeemeetings or weekly staff lunches. Other scheduling Applications do notuse these types of records. A user has to create equivalent entries bycreating a separate record for each instance of these recurring events.

Various problems arise when synchronizing these types of records. Let usconsider a situation when Application A uses recurring records whileApplication B does not. A synchronizing application must be able tocreate multiple entries for B for each recurring entry in A. It alsomust be able to identify some of the records in database B as instancesof recurring records in database A. Also, many Applications which allowrecurring records also permit revision and editing of single instancesof recurring records without affecting the master recurring record.Moreover, single instances of a recurring event in Application B may bechanged or deleted. The recurring master may also be changed which hasthe effect of changing all instances. These changes make it harder toidentify multiple entries in database B as instances of a recurringrecord in database A. Moreover, synchronization must take these changesinto account when updating records in one or the other database.

SUMMARY OF THE INVENTION

The invention provides a technique for synchronizing databases in whichdifferent techniques are used for storing a recurring event. A databasein which the recurring event is, for example, stored as a singlerecurring record can be synchronized with a database in which the samerecurring event is stored as a series of individual records. Theindividual records are processed to form a synthetic recurring recordrepresenting the set of individual records, and synchronizationdecisions are based on a comparison of the synthetic record to therecurring record of the other database. Following synchronization, thesynthetic record can be “fanned” back into the individual records toupdate the database containing individual records, and the updatedrecurring record can be written hack to the other database. In this way,the invention avoids the problems encountered with prior methods, inwhich synchronization resulted in a recurring record being transformedinto a series of individual records.

The invention features a computer implemented method of synchronizing atleast a first and a second database, wherein the manner of storing a setof recurring instances differs between the first and second databases,and at least the first database uses a recurring record to store the setof recurring instances. A plurality of instances in the second databaseare processed to generate a synthetic recurring record representingrecurring instances in the second database, the synthetic recurringrecord of the second database is compared to a recurring record of thefirst database, and synchronization is completed based on the outcome ofthe comparison.

Preferred embodiments of the invention may include one or more of thefollowing features: Completing synchronization may include adding,modifying, or deleting the synthetic recurring record or the recurringrecord. Following synchronization, the synthetic recurring record may befanned back into a plurality of single instances. The set of recurringinstances may be stored in the second database as a plurality of singleinstances. The set of recurring instances may be stored in the seconddatabase as a recurring record having a different record structure thanthe recurring record of the first database. A history file may be storedcontaining a record representative of the presence of a recurring recordor a synthetic recurring record in past synchronizations.

The invention may be implemented in hardware or software, or acombination of both. Preferably, the technique is implemented incomputer programs executing on programmable computers that each includea processor, a storage medium readable by the processor (includingvolatile and non-volatile memory and/or storage elements), at least oneinput device, and at least one output device. Program code is applied todata entered using the input device to perform the functions describedabove and to generate output information. The output information isapplied to one or more output devices.

Each program is preferably implemented in a high level procedural orobject oriented programming language to communicate with a computersystem. However, the programs can be implemented in assembly or machinelanguage, if desired. In any case, the language may be a compiled orinterpreted language.

Each such computer program is preferably stored on a storage medium ordevice (e.g., ROM or magnetic diskette) that is readable by a general orspecial purpose programmable computer for configuring and operating thecomputer when the storage medium or device is read by the computer toperform the procedures described in this document. The system may alsobe considered to be implemented as a computer-readable storage medium,configured with a computer program, where the storage medium soconfigured causes a computer to operate in a specific and predefinedmanner.

Other features and advantages of the invention will become apparent fromthe following description of preferred embodiments, including thedrawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic drawing of the various modules constituting thepreferred embodiment.

FIG. 2 is a representation of the Workspace data array.

FIG. 3 is the pseudocode for the Translation Engine Control Module.

FIG. 4 shows the relationship between

FIGS. 4A and 4B; FIGS. 4A and 4B, in combination, are the pseudocode forgenerating the parameter Table.

FIG. 5 shows the relationship between

FIGS. 5A and 5B; FIGS. 5A and 5B, in combination, are the pseudocode forfanning a recurring record.

FIG. 6 is the pseudocode for the Synchronizer loading the History File.

FIG. 7 is the pseudocode for matching key fields (Key_Field_Match).

FIG. 8 is the pseudocode for loading records of B_Database intoWorkspace.

FIG. 9 is the pseudocode for A Sanitization of B_Database records inWorkspace.

FIG. 10 is the Pseudocode for a specific example of a rule of data valueused for sanitization.

FIG. 11 is the pseudocode for orientation analysis.

FIG. 12 is the pseudocode for Conflict Analysis And Resolution (CAAR).

FIG. 13 is the pseudocode for analyzing unique ID bearing FannedInstance Groups (FIGs).

FIG. 14 is the pseudocode for expanding CIGs created from unique IDbearing records.

FIG. 15 is the pseudocode for finding weak matches for a record.

FIG. 16 shows the relationship between FIGS. 16A and 16B;

FIGS. 16A and 16B, in combination, are the pseudocode for findingmatches between recurring items and non_unique ID bearing instances.

FIG. 17 is the pseudocode for completing Same Key Group (SKG) analysis.

FIG. 18 is the pseudocode for setting the Maximum_CIG_Size for every CIGanalyzed in FIG. 17.

FIG. 19 shows the relationship between

FIGS. 19A and 19B; FIGS. 19A and 19B, in combination, are the pseudocodefor setting CIG_Types.

FIG. 20 is the User Interface for conflict resolution when the Notifyoption is selected.

FIG. 21 is the pseudocode for merging exclusion lists.

FIG. 22 is a look up table used by the function in FIG. 21.

FIG. 23 is a look up table used by the function in FIG. 21.

FIG. 24 is a look up table used by the function in FIG. 21.

FIG. 25 shows the relationship between FIGS. 25A and 25B;

FIGS. 25A and 25B, in combination, are a pseudocode for unloadingrecords from Workspace to a non-rebuild-all database.

FIG. 26 shows the relationship between FIGS. 26A, 26B, 26C, and 26D;

FIGS. 26A, 26B, 26C, and 26D in combination, illustrate the look uptable for determining loading outcome results.

FIG. 27 shows the relationship between FIGS. 27A and 27B;

FIGS. 27A and 27B, in combination, are the pseudocode for fanningrecurring records of A-Database for unloading.

FIG. 28 is the pseudocode for unloading the History File.

FIG. 29 is a table showing cases in which Recurring Masters are fannedinto own database.

FIG. 30 is the pseudocode for loading records by a fast synchronizationTranslator.

FIG. 31 shows the relationship between FIGS. 31A and 31B;

FIGS. 31A and 31B, in combination, are the pseudocoe for loading recordsby a fast synchronization Translator.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 shows the relationship between the various modules of thepreferred embodiment. Translation Engine 1 comprises Control Module 2and Parameters Table Generator 3. Control Module 2 is responsible forcontrolling the synchronizing process by instructing various modules toperform specific tasks on the records of the two databases beingsynchronized. The steps taken by this module are demonstrated in FIG. 3.The Parameters Table Generator 3 is responsible for creating aParameter_Table 4 which is used by all other modules for synchronizingthe databases. Details of the Parameter_Table are described in moredetail below. The Synchronizer 15 has primary responsibility forcarrying out the core synchronizing functions. It is a table-driven codewhich is capable of synchronizing various types of databases whosecharacteristics are provided in the Parameter Table 4. The Synchronizercreates and uses the Workspace 16, which is a temporary data array usedduring the synchronization process.

A Translator 5 (A_Translator) is assigned to the A_database 13 andanother Translator 9 (B_Translator) to the B_database 14. Each of thedatabase Translators 5 and 9 comprises three modules: Reader modules 6and 10 (A_Reader and B_Reader), which read the data from the databases13 and 14; Unloader modules 8 and 12 (A_Unloader and B_Unloader), whichanalyze and unload records from the Workspace into the databases 13 and14; and Sanitizing modules 7 and 11 (A_Sanitizer and B_Sanitizer), whichanalyze the records of the other database loaded into the Workspace andmodify them according to rules of data value of its own database. In thepreferred embodiment, the modules of the A_Translator 5 are designedspecifically for interacting with the A_database 13 and theA_Application 17. Their design is specifically based on the record andfield structures and the rules of data value imposed on them by theA_Application, the Application Program Interface (API) requirements andlimitations of the A_Application and other characteristics of A_Databaseand A_Application. The same is true of the modules of B_Translator 9.These Translators are not able to interact with any other databases orApplications. They are only aware of the characteristics of the databaseand the Application for which they have been designed. Therefore, in thepreferred embodiment, when the user chooses two Applications forsynchronization, the Translation Engine chooses the two Translatorswhich are able to interact with those Applications. In an alternateembodiment, the translator can be designed as a table-driven code, wherea general Translator is able to interact with a variety of Applicationsand databases based on the parameters supplied by the Translation Engine1.

Referring to FIGS. 1, 2 and 3, the synchronization process is asfollows. The Parameter_Table 4 is generated by the Parameter TableGenerator 3. The Synchronizer 15 then creates the Workspace 16 dataarray and loads the History File 19 into the Workspace 16. The B_Readermodule 11 of the B_Translator reads the B_database records and sendsthem to the Synchronizer for writing into the Workspace. Following theloading of B_Database records, the A_Sanitizer module 8 of theA_Translator 5 sanitizes the B_Records in the Workspace. The A_Readermodule 7 of the A_Translator 5 then reads the A_Database records andsends them to the Synchronizer 16 for writing into the Workspace. TheB_Sanitizer module 12 of the B_Translator 9 then sanitizes the A_Recordsin the Workspace. The Synchronizer then performs the Conflict Analysisand Resolution (CAAR) on the records in Workspace. At the end of thisanalysis the user is asked whether he/she would like to proceed withupdating the A_ and B_databases. If so, the B_Unloader module of theB_Translator unloads the appropriate records into the B_database. TheA_Unloader module 6 then performs the same task for the A_Database.Finally, the Synchronizer creates a new History File 19.

FIG. 3 is the pseudocode for the preferred embodiment of the ControlModule 2 of the Translation Engine 1. Control Module 2 first instructsthe Parameter Table Generator 3 of the Translation Engine 1 to createthe Parameter_Table (Step 100). FIGS. 4A and 4B are the pseudocode forthe preferred embodiment of the Parameter Table Generator module 3. Theuser is first asked to choose whether to use a previously chosen andstored set of preferences or to enter a new set of preferences (Step150). Steps 151-165 show the steps in which the user inputs his/her newpreferences. In step 152, the user chooses whether to perform asynchronization from scratch or an incremental synchronization. In asynchronization from scratch, synchronization is performed as if thiswas the first time the two databases were being synchronized. In anincremental synchronization, the History File from the previous file isused to assist with synchronization. The user will likely chooseincremental synchronization if there has been a prior synchronization,but the user may choose to synchronize from scratch where the user wouldlike to start with a clean slate (perhaps due to significant change inthe nature of the data in the databases). The user then selects the twoApplications and related databases (A_Database and B_Database) to besynchronized (step 153). The user then chooses (step 154) whether theSynchronizer should use the default field mapping for those twodatabases during synchronization or the user will modify the fieldmapping. Field mapping is generally described in U.S. Pat. No. 5,392,390(incorporated by reference). In accordance with the user's preferences,the Parameter Table Generator then stores the appropriate A_Database toB_Database fields map (A→B_Map) and B_Database to A_Database fields map(B→A_Map) in the Parameter_Table (Steps 155-158 and 159-163,accordingly).

If in step 150 the user selected to use previously chosen and stored setof preferences (steps 166-171), those preferences are loaded and storedin the Parameter Table (steps 169-170).

In case of date bearing records such as appointments and ToDo lists, theuser enters the date range for which the user wants the records to besynchronized (step 172). The preferred embodiment allows the user to userelative date ranges (Automatic_Date_Range) (substeps 171 (a) and (b).For example, the user can select the date range to be 30 days into thepast from today's date and 60 days into the future from today's date.The Parameter Table Generator 3 then calculates and stores in theParameter_Table the Start_Current_Date_Range and End_Current_Date_Rangevalues, the two variables indicating the starting point and the endingpoint of the date range for the current synchronization session (step173-174).

In steps 174 and 175, various parameters identifying the characteristicsof the A_Database and Application and B_Database and Application areloaded from a database (not shown) holding such data for differentApplications. These are in turn stored in the Parameter_Table. One ofthe sets of parameters loaded and stored in the Parameter_Table is theField_List for the two databases. The Field_List_A and Field_List_Bcontain the following information about each field in the data structureof the two databases:

-   -   1. Field name.    -   2. Field Type.    -   3. Field Limitations.    -   4. No_Reconcile Flag.    -   6. Key_Field Flag.    -   7. Mapped_Field Flag.        Field name is the name given to the field which the Translator        for this Application uses. This name may also be the name used        by the Application. Field Type identifies to the Synchronizer 15        the nature of the data in a field, e.g., Data, Time, Boolean,        Text, Number, or Binary. The Field Name does not supply this        information to the Synchronizer. Field Limitations identifies        the various limitations the database manager imposes on the        contents of a field. These limitations include: maximum length        of text fields, whether the text field must be in upper-case,        range of permissible values (for example, in ToDo records        priority field, the range of permissible values may be limited        from 1 to 4), and whether a single line or multiple line field.

No_Reconcile flag indicates whether a field is a No_Reconcile field,meaning that it will not be used to match records nor will it besynchronized although it will be mapped and possibly used insynchronization. Almost all fields will not be designated asNo_Reconcile. However, sometimes it is necessary to do so. Key_Fieldflag indicates that a field should be considered as a key field by theSynchronizer 15.

Key fields are used by the Synchronizer in various stages ofsynchronization as will be discussed in detail below. The decision ofidentifying certain fields as key is based on examining the variousApplications to be synchronized, their data structure, and the purposefor which the database is used. Such examination reveals which fieldswould best function as key fields for synchronization. For example, foran address book database, the lastname, firstname, and company namefield may be chosen as key fields. For Appointments, the date field andthe description field may be chosen as key fields.

Mapped_Field flag indicates whether a field is mapped at all. TheSynchronizer uses this flag to determine whether it should use theA→B_Map or B→A_Map to map this field. Unlike a No_Reconcile field, anunmapped field will not be carried along through the synchronization.

Another set of parameters in the Parameter_Table identify the TranslatorModules 13, 14 for the two Applications which the user has selected.Because each Application is assigned its own Translator, it is necessaryto identify to the Command Module and the Synchronizer which Translatorsshould he used.

In step 102 of FIG. 1, the Translation Engine instructs the Synchronizerto load the History File. History File is the file which was saved atthe end of last synchronization. It contains the history of the previoussynchronization which is necessary for use with the currentsynchronization in case of Incremental Synchronization. Records from theA_Database and B_Database are analyzed against the records of thehistory file to determine the changes, additions, and deletions in eachof two databases since last synchronization and whether additions,deletions, or updates need to be done to the records of the databases.Referring to FIGS. 5A and 5B, in steps 200-201, the Synchronizer findsthe appropriate History file to be loaded. If Synchronization fromScratch flag is set, the History File is deleted (step 203). If noHistory File is found, the synchronization will proceed as if it was asynchronization from scratch (step 204). If the Field Lists stored inthe History File are not the same as the current Field Lists in theParameter_Table, or the mapping information is not the same, thesynchronization will proceed as synchronization from scratch because thedifferences indicate that the History File records will not properlymatch the database records (steps 206-209).

In step 210, the Synchronizer uses the Field_List for database B tocreate the Workspace 16. It is a large record array which theSynchronizer uses during synchronization. Referring to FIG. 2, Workspace16 consist of two sections. First, the Synchronizer uses the Field_Listfor the B_Database to make a record array 21 which has all thecharacteristics of the B_Database record structure. In addition, in eachrecord in the Workspace, certain internal fields are added. One field is_subtype containing Origin Tags. Two other fields, called Rep_Basic andRep_Excl, are included for all Appointment and ToDo Sections. TheRep_Basic field gives a full description of the recurrence pattern of arecurring record. It includes the following parameters:

-   -   1. Basic_Repeat_Type    -   2. Frequency    -   3. StopDate    -   4. other parameters    -   5. Rep_Excl

Basic_Repeat_Type contains the variable which indicates whether therecurring record is a daily, weekly, monthly (same date each month),monthly by position (e.g., 3rd Friday of each month), yearly (e.g., July4th each year), yearly by Position (e.g., 3rd Friday of September eachyear), quarterly, etc. This variable is set to No_Repeat fornon-recurring records.

Frequency indicates whether the pattern is, for example, for every week,every other week, etc. StartDate and StopDate show the first date andlast date in the pattern. Some other parameters in the Rep_Basicinclude, for example, a list of days to be included for the pattern(e.g. I plan to hold a weekly staff meeting every Thursday starting Nov.15, 1997.)

Rep_Excl is the exclusion list. It is a list of dates which at somepoint belonged to the recurring record, but have since been deleted ormodified and no longer are an event represented by the recurring record.

Since some databases do not provide for recurring types of records, thesynchronization process sometimes must create single records for each ofthe instances of a recurring record for those databases. For example,for a recurring lunch every Thursday, the synchronization must produce asingle record for each Thursday in such a database. This is accomplishedby the process of fanning which uses Rep_Basic. Each of those instancesis called a fanned instance. FIG. 6 sets out the preferred embodiment ofthe process of fanning a record.

Fanning of recurring records also takes into account another set ofconsiderations regarding date range limitations and usefulness ofinstances to the user.

First, fanning is limited to the applicable date range. Second, thenumber of fanned instances is limited. When synchronizing Databases Aand B, the preferred embodiment permits different sets of limits onfanned instances to be established for each Database. This, for example,assists with managing storage capacity of a memory-constrained handhelddevice when being synchronized with a database on a desktop PC.

If the current Date Range is large enough to accommodate more than themaximum number of instances which might be generated, those instanceswill be chosen which are likely to be most useful to the user. In thepreferred embodiment, it is assumed that future instances are alwaysmore useful than past instances, that near future instances are moreuseful than distant future instances, and that recent past instances aremore useful than distant past instances. Therefore, based on theseassumptions, a fanning date range is calculated (FIG. 6, step 236).

Referring to FIG. 2, in the second step of creating the Workspace, theSynchronizer establishes an Extended Index Array 20 which has an indexentry associated with each entry in the record array. Each indexcontains the following variables:

-   -   1. Next_In_CIG:    -   2. Next_In_SKG:    -   3. Next_In_FIG.    -   4. Key_Field_Hash    -   5. A_Unique_ID_Hash    -   6. B_Unique_ID_Hash    -   7. Non_Key_Field_Hash    -   8. Non_Date_Hash    -   9. Exclusion_List_Hash    -   10. Start_Date&Time    -   11. End_Date&Time    -   12. Various bit flags

Next_In_CIG is a linkage word, pointing to next member of the sameCorresponding Item Group (CIG). A CIG is a group of records, one fromeach database and the History File, if applicable, which represent thesame entry in each of the databases and the History File. There may beone, two or three records in a CIG. Next_In_SKG is a linkage word,pointing to next member of the Same Key Fields Group (SKG). An SKG is agroup of records having the same key fields. Next_In_FIG is a linkageword, pointing to the next member of the Fanned Instances Group (FIG). AFIG is the group of fanned instances which correspond to a singlerecurring record.

Key_Field_Hash is hash of all Key_Fields. A_unique _ID_Hash is hash ofunique ID, if any, assigned by A_Database. B_unique_ID_Hash is hash ofunique ID, if any, assigned by B_Database. Non_Key_Field_Hash is hash ofall Non-Key Match Field, a Match Field being any mapped field which isnot flagged as No_Reconcile. Non_Date_Hash is hash of all Non-DateNon-Key Match Fields. Exclusion_List_Hash is hash of recurring record'sexclusion list.

Start_Date&Time and End_Date&Time are used for Appointment and ToDo typerecord only, indicating the start and end date and time of the record.They are used to speed up comparing functions throughout thesynchronization. Hash values are also used to speed up the process ofcomparison. The preferred embodiment uses integer hashes. Hash valuecomputation takes into account certain rules of data value for fields,as will be described in more detail below.

In the preferred embodiment, the record array 21 is stored on magneticdisk of a computer whereas the Extended Index 20 is held resident inmemory. The Extended Indexes have record pointer fields which point toeach of the records on the disk file.

The Control Module 2 now instructs the synchronizer to load the HistoryFile into the Workspace (FIG. 3, step 102). Referring to FIG. 6, thesynchronizer loads the records beginning in first available spot in theWorkspace (step 211). The Synchronizer then performs an analysis on eachof the records and resets some of the values in the records (steps212-228). The records are also checked against the current date rangeand those falling outside of it are marked appropriately for Fastsynchronization function, which will be described below. In case ofrecurring records, if any of the instances is within the current daterange, then the recurring record itself will be considered within thecurrent date range (steps 217-227).

The synchronizer then builds SKGs by finding for each history record onerecord which has matching key fields and by placing that record in theSKG of the history record (step 215-216). Referring to FIG. 7, steps250-258 describe the Key_Field_Match function used for matching recordsfor SKG.

When comparing two records or two fields, in the preferred embodiment,the COMPARE function is used. The COMPARE function is intelligentcomparison logic, which takes into account some of the differencesbetween the rules of data value imposed by the A_Application and theB_Application on their respective databases. Some examples are asfollows. The COMPARE function is insensitive to upper and lower caseletters if case insensitive field attribute is present. Because someApplications require entries to be in all capital letter, the COMPAREfunction ignores the differences between upper and lowercase letters.The COMPARE function takes into account any text length limitations. Forexample, when comparing “App” in the A_Database and “Apple” in theB_Database, the COMPARE function takes into account that this field islimited to only 3 characters in the A_Database. It also takes intoaccount limits on numerical value. For example, priority fields in theA_Application may be limited to only values up to 3, whereas in theB_Application there may not be any limitation. The COMPARE functionwould treat all values in B_records above 3 as 3.

The COMPARE function may ignore various codes such as end of linecharacters. It may strip punctuation from some fields such as telephonenumbers and trailing white space from text fields (i.e “Hello” istreated as “Hello”). It also considers field mapping. For example, ifthe only line that is mapped by the A→B_Map is the first line of afield, then only that line is compared. When comparing appointmentfields, because different databases handle alarm date and timedifferently when Alarmflag is false, the COMPARE function treats them asequal even though the values in them are not the same. It skips AlarmDate and Time, if the Alarm Flag is False. It also ignores exclusionlists when comparing recurring records.

In an alternate embodiment, the COMPARE function may take into accountmore complicated rules for data value of the two Applications, such asthe rules for data value imposed by Microsoft Schedule+, describedabove. Such a COMPARE function may be implemented as a table drivencode, the table containing the rules imposed by the A_Application andthe B_Application. Because the COMPARE function has a specificcomparison logic and takes into account a number of rules, the hashinglogic must also follow the same rules. It should be noted that theCOMPARE function is used throughout the preferred embodiment for fieldcomparisons.

Now that the History File is loaded into the Workspace, the ControlNodule 2 instructs the B_Translator 13 to load the B_Database records(FIG. 3, step 103). Referring to FIG. 8, steps 300-308, the B_Readermodule 11 of the B_Translator 13 loads each B_record which has the rightOrigin Tag, which will be explained in more detail below.

The record must also be within the loading date range, which is aconcatenation of the previous and current date ranges. The B_Translatorsends these records to the Synchronizer which in turn stores them in theWorkspace. When synchronizing with a date range limitation, all recordswhich fall within either the previous or the current date ranges areloaded. The current date range is used during unloading to limit theunloading of the records to only those records which fall within thedatabase's current date range. In an alternate embodiment of theinvention, each database or Application can have its own date range foreach synchronization.

Most Applications or databases permit record-specific and field-specificupdates to a Database. But some Applications or databases do not.Instead the Translator for these Application must re-create the wholedatabase from scratch when unloading at the end of synchronization.These databases are identified as Rebuild_All databases. To accommodatethis requirement all records from such a database must be loaded intothe Workspace, so that they can later be used to rebuild the wholedatabase. These databases records, which would otherwise have beenfiltered out by the date range or the wrong origin tag filters, areinstead marked with special flag bits as Out_Of_Range orWrong_Section_Subtype. These records will be ignored during thesynchronization process but will be written back unmodified into thedatabase from which they came by the responsible Unloader module 6, 10.

Control Module 2 next instructs the A_Translator 5 to sanitize theB-records. Referring to FIG. 9, steps 350-361, the A_Sanitizer module 8of the A_Translator 5 is designed to take a record having the form of anA_Record and make it conform to the specific rules of data value imposedby the A_Application on records of the A_Database. A_Sanitizer is notaware which database's field and records it is making to conform to itsown Application's format. It is only aware of the A_Application's fieldand record structure or data structure. Therefore, when it requests afield from the sanitizer using the A_Database field name, it is askingfor fields having the A_Database data structure. The Synchronizer, insteps 375-387, therefore maps each record according to the B→A_Map. Inturn, when the Synchronizer receives the fields from the A_SANITIZER, itwaits until it assembles a whole record (by keeping the values in acache) and then maps the record back into the B format using theA→B_Map.

How a record or a field is sanitized in step 354 and 357 depends on therules of data value imposed by the A_Application. For example, all ofthe logic of intelligent comparison in the COMPARE function describedabove can be implemented by sanitization. However, sanitization is bestsuited for more complex or unique types of database rules for datavalue. For example, consider the Schedule+ rules regarding alarm bearingTasks records described above. FIG. 10 shows a sanitization method formaking records of incompatible databases conform to the requirements ofSchedule+. Without sanitization, when a Tasks record of a Schedule+database is compared to its corresponding record in another database,the Tasks record may be updated in fields which should be blankaccording to the Schedule+ rules of data value. Such an update maypossibly affect the proper operation of Schedule+ after synchronization.

Referring to FIG. 11, following sanitization of all B_Records into theWorkspace, the Synchronizer sets the values for the Extended Index ofeach record based on the record's values (steps 451-459). Also if therecords in the B_Database bear a unique ID, and matches for those uniqueIDs are found in the H_Records in the Workspace, the two records arejoined in a CIG because they represent the same record in both HistoryFile and B_Database (step 462). The record is also joined to an SKG itmay belong to (step 464). The loading of B_Records is now complete.

The Control Module 2 of the Translation Engine 3 now instructs theA_Translator 5 to load the records from the A_Database (step 105). Theloading process for the A_Records is the same as the loading process forthe B_Database, except for some differences arising from the fact thatrecords in the Workspace are stored according to the B_Database datastructure. Therefore, as the synchronizer 15 receives each A_record fromthe A_Reader module 7 of the A_Translator 5, the Synchronizer maps thatrecord using the A→B_Map before writing the record into the nextavailable spot in the Workspace. Since the A records are mapped into theB_Record format, when the B_Sanitizer is instructed by the ControlModule 2 to begin sanitizing those records and starts asking for themfrom the synchronizer, they already have the B_Database format.Therefore, the synchronizer 15 does not need to map them before sendingthem to the B_Sanitizer module 12 of the B_Translator 19. For the samereason, there is no need for them to be mapped once they are sent backby the B_Sanitizer after having been sanitized. Once all the records areloaded, the records will undergo the same orientation analysis that theB_Records underwent (FIG. 11).

At this point, all records are loaded into the Workspace. SKGs arecomplete since every record at the time of loading is connected to theappropriate SKG. CIGs now contain all records that could be matchedbased on unique IDs. At this point, the records in the Workspace will beanalyzed according to Conflict Analysis and Resolution (“CAAR”) which isset out in FIG. 12 and in more detail in FIGS. 13-18 and correspondingdetailed description.

First, in step 500, ID bearing fanned instances in the History Filerecords are matched to the fanned instances in the ID bearing databasefrom which they came. The records from the database which have remainedunchanged are formed into a new FIG. A new Synthetic Master is createdbased on those records and joined to them. The records which have beenchanged or deleted since last synchronization are set free as singlerecords. They also result in a new exclusion list being created based onan old exclusion list and these new single records.

Second, in step 501, matches are sought for the ID based CIGs which arethe only CIGs so far created in order to increase the membership ofthose CIGs. Preferably an exact all fields match is sought betweencurrent members of a CIG and a new one. Failing that, a weaker match issought.

Third, in step 502, master/instances match is sought between recurringrecords and non-unique ID bearing instances by trying to find thelargest group of instances which match certain values in the RecurringMaster.

Fourth, in step 503, the items remaining in the SKGs are matched upbased on either exact all field match or master/instance match, or aweaker match.

Fifth, in step 501, the appropriate CIG Types are set for all the CIGs.CIG_Types will determine what the outcome of unloading the records willbe.

Referring to FIG. 13, first step in CAAR is analyzing unique ID bearingFanned Instance Groups. This analysis attempts to optimize using uniqueIDs assigned by databases in analyzing fanned instances of recurringrecords.

The analysis is performed for all Recurring Masters (i.e. all recurringrecords) which have ID-bearing fanned instances (or FIG records) in theH_File (step 550). All FIG records in the History File associated with aRecurring Master are analyzed (steps 551-559). They are all removed fromthe SKG. If a FIG record is a singleton CIG, it means that it wasdeleted from the database since the previous synchronization. Therefore,it is added to the New_Exclusion_List (step 553). If a FIG record is adoubleton and is an exact match, it means that the record was notmodified since the previous synchronization. In this case, the recordfrom the database is also removed from SKG (step 555). If a FIG recordis a doubleton but is not an exact match for its counterpart in thedatabase, it means that the record was changed in the database. TheHistory File record is treated as a deletion and therefore added to theNew_Exclusion_List. The modified record in the database, which does notmatch the recurring record any longer, is treated as a free standingrecord un-associated with the Recurring Master (step 557).

Upon analysis of all FIG records, a new record, the Synthetic Master, iscreated and joined in a CIG with the Recurring Master (step 231-236).The Synthetic Master has the same characteristics as the RecurringMaster, except that it has a new exclusion list which is a merger of theNew_Exclusion_List and the Exclusion_List of the Recurring Master (step563). Also a new FIG is created between the Synthetic Master and theCIG-mates of all FIG records from the History File (step 565).

In steps 567-569, the Synchronizer checks to see if there are someinstances of the Recurring Master which fall within the previoussynchronization's date range but fall outside of the currentsynchronization's date range. If so, the Fan_Out_Creep flag is set,indicating that the date range has moved in such a way as to require therecord to be fanned for the database before unloading the record. TheFan_Out_Creep flag is an increase in the value in the Non_Key_Field Hashof the Recurring Master. In this way, the Recurring Master during theunloading of the records will appear as having been updated since thelast synchronization and therefore will be fanned for the current daterange.

In step 570, all the FIG records analyzed or created in this analysisare marked as Dependent FIGs. This results in these records beingignored in future analysis except when the recurring records to whichthey are attached are being analyzed.

At the end of the above analysis, all the records having a unique IDassigned by their databases have been matched based on their unique ID.From this point onward, the records which do not have unique IDs must bematched to other records based on their field values. In the preferredembodiment, there are two categories of field value matches: strongmatches and weak matches. A strong match between two records that havematching key fields is when non-key fields of the two records match orit is a Recurring Master and a fanned instance match (FIG. 14, steps606-610). Referring to FIG. 15, a weak match between two records thathave matching key fields is when the following are true: each of the tworecords are from different origins, because two records from the samesource should not be in a CIG (e.g., A_Database and History File); eachis not a weak match for another record because there is no reason toprefer one weak match over another; each is not a Dependent_FIG sincethese records do not have an independant existence from their recurringmasters; both records are either recurring or non-recurring since arecurring and a nonrecurring should not be matched except if one is aninstance of the other in which case it is a strong match; and, in caseof non-recurring, they have matching Key_Date_Field which is the same asthe Start_Date in the preferred embodiment because items on the samedate are more likely to be modified versions of one another.

Referring to FIG. 14, these two types of matching are used to matchrecords to existing CIGs for History File records which have beencreated based on matching unique IDs. Only doubleton CIGs are looked at,because singleton CIGs are handled in step 504 of FIG. 12 and tripletonCIGs are complete (steps 601-604). If a strong match is found, then ifthe record was a weak match in another CIG, it is removed from that CIG,and new weak match is found for that CIG (612-614). While weak matchesare left in SKGs in case they will find a strong match, strong matchesare removed from their SKGs (step 614). If a strong match is not found,then a weak match is sought (steps 617-620). All records in the CIG areremoved from SKG if no weak match is found, because this means thatthere is no possibility of even a weak match for this record (step 619).

The next step in CAAR is finding non-unique ID bearing instances forrecurring items (FIG. 12, step 503). Referring to FIGS. 16A and 16B,this analysis takes place only if the database from which instancesmatching a recurring record are sought does not provide unique ID or ifwe are synchronizing from scratch (steps 650-653). The goal of thisanalysis is to find matching instances for each Recurring Master from adifferent source than the Recurring Master. This analysis counts thenumber of records in SKG of the Recurring Master which have matchingNon_Date_Hash value (steps 665-669). The group of matching SKG recordshaving the same non_Date_Hash value and having the highest number ofmembers (if the number of members exceeds 30% of unexcluded instances)is then formed into a Homogeneous_Instances_Group (steps 670-672). ASynthetic Master is created using the Rep_Basic of the Recurring Masterand using the values from the homogeneous instances group. An Exclusionlist is created based on the items belonging to the recurrence patternbut missing from the Homogeneous_Instances_Group. The Synthetic Masteris added to the CIG of the Recurring Master (steps 673-678). A new FIGfor the Synthetic Master is then created using theHomogeneous_Instances_Group (step 679). These records are removed fromany CIGs to which the_(y) belonged as weak matches and new weak matchesare sought for those CIGs (steps 680-684). Since the records inHomogeneous_Instances_Group have now been matched to a recurring record,they are marked as Dependent_FIGs (step 683). The Recurring Master's CIGis then marked with Fan_Out_Creep flag, if necessary (step 685).

The next step in CAAR is completing analysis of records in SKGs (FIG.12, step 504). Referring to FIG. 17, this analysis attempts to increasethe population of CIGs up to a maximum by finding key field basedmatches with records from a source different from those of the CIGrecords. This analysis is performed by analyzing all the records in theSKGs except for the singleton SKGs (steps 703 and 712). The first thingis to remove any members that have already been marked as WEAK matchesattached to ID-based doubleton CIGs. Those are left in the SKG up tothis point to allow for the possibility that a STRONG match would befound instead. But that is not possible any longer (steps 713-715). Oncethe weak matches have been removed, all remaining SKG members belong tosingleton CIGs. Any non-singleton CIGs which are formed from here onwill be purely key field based.

Throughout the remaining SKG Analysis we are careful not to seekH_Record-A_Record or H_Record-B_Record matches for unique ID-bearingSource, since that would violate the exclusively ID-based matchingscheme that applies in such cases. Note however that anA_Record-B_Record match is acceptable even if both A_Database andB_Database are unique ID-bearing databases.

Given that Key Field should not be performed where ID based matches areavailable (or otherwise there may be matches between records withdiffering IDs), there are limits to how big CIGs can get at this point.If both A and B_Databases are unique ID-bearing, any remaining H_Recordmust remain in Singleton CIGs, because they are prohibited from formingkey fields based matches with items from either databases. SuchH_Records are simply removed from the SKG when they are encountered. Ifjust one of the two databases being synchronized is unique ID-bearingthen the maximum population that any CIG can now attain is 2 (FIG. 18,steps 750-751). If neither database is unique ID bearing then the CIGMax Size is three. For every CIG which is analyzed in FIG. 17, theCIG_Max_Size is set according to this logic. When a CIG reaches itsmaximum possible population all of its members are removed from theappropriate SKG.

First, strong matches for the H-records are searched for, before tryingto find A-B matches. If both Databases are non-unique ID-bearing thentwo strong matches for each H_Record, an H-A and an H-B match, aresought (steps 715-720). If finding a strong match results in reachingthe CIG_Max_Size, all members of the CIG are removed from the SKG (step721).

When maximum CIG population is 3, weak matches are sought for strongmatching CIG doubleton in order to build triplet CIGs. The first weaklymatching SKG member is added to the CIG (steps 722-728). Whether or nota weak match is found for any of the doubleton CIGs, its members areremoved from the SKG (step 726). As there are no strong matches left inthe SKG, weak matches are found for any remaining SKG members and joinedto them in CIGs (steps 722-725).

At this stage, all CIGs are built. They must now be examined todetermine what needs to be done to these records so that the databasesare synchronized, i.e. whether the records in the CIGs need to be added,deleted or changed in the two databases. First step is determining theCIG_TYPE which represents the relation between the records. Thefollowing CIG types are defined, all using a 3-digit number thatrepresents values found for A_DATABASE, History File, and B_Database,respectively:

-   -   1. 001—record is “new” in the B_DATABASE    -   2. 010—record is present in History, but absent in both        A_Database and B_Databases    -   3. 100—record is “new” in the A_Database    -   4. 101—record is “new” in both A_Database and B_DATABASE; same        in both    -   5. 102—record is “new” in both A_Database and B_DATABASE;        different in each (conflict)    -   6. 110—record deleted from B_DATABASE    -   7. 011—record deleted from A_Database    -   8. 012—record deleted from A_Database and changed on B_DATABASE        (DEL vs CHANGE conflict)    -   9. 210—record changed on A_Database and deleted from        B_DATABASE(DEL vs CHANGE conflict)    -   10. 111—record unchanged since previous synchronization    -   11. 112—record changed on B_DATABASE only since previous        synchronization    -   12. 211—record changed on A_Database only since previous        synchronization    -   13. 212—record changed identically on both since previous        synchronization    -   14. 213—record changed differently on each since previous        synchronization (conflict)    -   15. 132—a conflict (102 or 213) was resolved by forming a        compromise value; Update both    -   16. 13F—created when a 132 Update both CIG is Fanned into the        B_DATABASE

FIGS. 19A and 19B show the method used for setting all except the lasttwo CIG_Types which are set in other operations.

Four of the CIG types assigned above involve conflicts: 102, 213, 012,and 210. Conflicts are those instances where a specific conflictresolution rule chosen by the user or set by default, or the user's caseby case decision, must be used to determine how the records from thedatabases should be synchronized. CIG types 012 and 210 are cases wherea previously synchronized record is changed on one side and deleted onthe other. In the preferred embodiment, such conflicts are resolvedaccording to the rule that CHANGE overrules the DELETE. So the netresult for CIG type 012 is to add a new record to the A_Database tomatch the record in the B_DATABASE. The reverse is true for CIG type210, where a new record is added to the B_Database. In an alternateembodiment, the user may be allowed to register an automatic preferencefor how to resolve such conflicts or decide on a case-by-case basis aconflict resolution option.

The other two conflict types—102 and 213—are resolved in the preferredembodiment according to the Conflict Resolution Option established bythe user. First, the user may choose to ignore the conflict. This optionleaves all 102 and 213 conflicts unresolved. Every time synchronizationis repeated the conflict will be detected again and ignored again, aslong as this option remains in effect and as long as the conflictingrecords are not changed by other means.

The user may choose to add a new record to each of the two databases.This option resolves 102 and 213 conflicts by adding the new A_Record tothe B_Database, and adding the new B_Record to the A_Database. Thisoption is implemented by breaking a 102 CIG into two separate CIGs(types 100 and 001) and a 213 CIG into three separate CIGs (types 100,010, and 001). Subsequent processing of those descendant CIGs causes newrecords to be added across and stored in the History File.

The user may elect that A_Database records should always trump or winover B_database records. This option is implemented by changing the CIGtype to 211—the processing during unloading the records changes therecord value in the B_Database to match the current record value in theA_Database.

The user may elect that B_Database records should always trump or winover B_database records. This option is implemented by changing the CIGtype to 112—the processing during unloading the records changes therecord value in the A_Database to match the current record value in theB_Database.

The user may choose to be notified in case of any conflict. The user isnotified via a dialog box 30, shown in FIG. 20, whenever a CIG typeconflict of 102 or 213 arises. The dialog box shows the record that isinvolved in the conflict 31. It also shows the A_Database 32 andB_Database 33 values for all conflicting fields, in a tabular display,with Field Names appearing in the left column 34. A dropdown list (notshown) in the lower left hand corner of the dialog 37, offers a total ofthree choices—add, ignore, and update. The use may choose to add newrecords or ignore the conflict. The user may also choose that theA_Record or B_Record should be used to update the other record. The usermay also decide to create a compromise record by choosing values ofdifferent fields and then choosing update option. In this case, the CIGtype is changed to 132, which results in an updating both databases withthe new record compromise record.

When the user has chosen to be notified in case of conflict, if the userchooses to ignore conflict or that either the record of the A_Databaseor the B_DATABASE should win, the CIG type is left as a conflict CIGtype (102 or 213) and a separate Conflict Resolution Choice is stored inthe FLAGS word associated with each CIG member.

The final step in setting CIG_Types is the process for dealing withdifficulties which arise from exclusion lists. For example, in a tripleRecurring Master CIG, suppose the History File Recurring Master does nothave any excluded instances. The A_Record has the following exclusionlist:

-   -   12/1/96, 12/8/96        The B_Record has the following exclusion list:    -   1/1/97, 1/8/97, 1/15/97, 1/22/97, 1/29/97

If comparison of the Recurring Masters includes comparing exclusion listField Values, this set of changes would cause the Synchronizer to reporta CIG type 213 conflict.

If the Conflict Resolution Option is set to A_Database record wins, thenthe outcome prescribed by the Synchronizer would be for the A_Databaseto keep its exclusion list as is and for the B_Database to make itsexclusion list match that of the A_Database.

The result would be to have a lot of duplicate entries in bothDatabases. The A_Database would have five duplicate entries in January97—that is the five unmodified Recurring Master instances, plus the fivemodified instances added across from B_Database to A_Database. TheB_Database would have five duplicate entries in January 97, sincesynchronization has wiped out the five exclusions that were previouslyrecorded in the B_Database exclusion list.

Two steps are implemented for dealing with this problem. First, theCOMPARE function does not take into account exclusion list differenceswhen comparing recurring records. Second, referring to FIG. 21, any newexclusions added on to one recurring record will be added to the otherrecord. The merging of exclusion lists is done regardless of any updatesor conflicts, even unresolved conflicts, between the A_Database andB_Database copies of a Recurring Master. One exception is for CIG type102 conflict which is left unresolved where Exclusion lists are notmerged, because the user has chosen to leave those records as they are.

In most cases where it is necessary to merge exclusion lists, the CIGtypes and/or the Conflict Resolution Choice to arrange for all necessaryupdates to be performed during the unloading phases of synchronization.

First, A_Database and B_Database records' exclusion lists are compared.In case of databases which do not permit recurring items, the exclusionlist of the Synthetic Master is compared to the recurring record of theother database (step 852). If there is no difference, then nothing isdone (step 853). If there are differences, then it is determined whichexclusions appear only in one record. This comparison always yields oneof the following scenarios: (1) all one-side-only Exclusions are on theA_Database (so Exclusions should be added to the B_Database); (2) allone-side-only Exclusions are on the B_Database (so Exclusions should beadded to the A_Database); and (3) there are one-side-only Exclusions onboth sides (so Exclusions should be added to both databases).

In each of these cases a separate table is used to look up instructions,for how to handle each specific situation (FIGS. 22-24). The tablescover all possible combinations of previous CIG types and outcome codeswith all possible exclusion list changes (new and different exclusionsadded on A_Database, or on B_Database, or on both sides). FIG. 22 tableis used in case of scenario 1. FIG. 23 table is used in case of scenario2. FIG. 24 table is used in case of scenario 3 (FIG. 21 steps 854-856).

The analysis of records is now complete, and the records can be unloadedinto their respective databases, including any additions, updates, ordeletions. However, prior to doing so, the user is asked to confirmproceeding with unloading (FIG. 3, step 108-109). Up to this point,neither of the databases nor the History File have been modified. Theuser may obtain through the Translation Engine's User Interface variousinformation regarding what will transpire upon unloading.

If the user chooses to proceed with synchronization and to unload, therecords are then unloaded in order into the B_Database, the A_Databaseand the History File. The Unloader modules 6,10 of the Translators 5,9perform the unloading for the databases. The Synchronizer creates theHistory File and unloads the records into it. The Control Module 2 ofthe Translation Engine 1 first instructs the B_Translator to unload therecords from Workspace into the B_Database. Referring to FIGS. 25A and25B, for each CIG to be unloaded (determined in steps 902-907), based onthe CIG_TYPE and which database it is unloading into (i.e., A or B), theunloader looks up in the table in FIGS. 26A-26D the outcome that must beachieved by unloading—that is, whether to update, delete, add, or skip(Leave_Alone) (step 908). In steps 909-913, the unloader enforces daterange restriction for a database subject to date range. The user mayselect, or a selection may be made by default, whether to enforce thedate range sternly or leniently. In case of stern enforcement, allrecords outside of the current date range would be deleted. This isuseful for computers with small storage capacity. In case of lenientenforcement, the records are left untouched.

Based on the result obtained from looking up the unloading outcome inthe table, the unloader then either adds a new record (steps 920-926),deletes an existing record (steps 914-919), or updates an existingrecord (steps 927-933). It should be noted that because we only updatethose fields which need to be updated (step 928), the fields which weresanitized but need not be updated are not unloaded. Therefore, thevalues in those fields remain in unsanitized form in the database.

Referring to step 914, in sonic Applications when a Recurring Mastermust be added or updated, the record may have to be fanned out despitethe ability of the Application to support recurring records. Forexample, the Schedule+ Translator is generally able to put almost anyRecurring Master Item into Schedule+ without fanning, but there are someexceptions. The Schedule+ Translator uses one Schedule section to handleall appointments and events. For appointments, almost any recurrencepattern is allowed, but for events the only allowable true repeat typeis YEARLY. DAILY recurring events can be dealt with by being translatedinto Schedule+ multi-day events which are not recurring but extend overseveral days by setting the EndDate some time after the Start Date. Butfor the DAILY case there are restrictions. In particular exclusions inthe midst of a multi-day Schedule+ event cannot be created. So theTranslator decides that if section type is ToDos or the item is anon-Event Appointment, then the record need not be fanned out. But ifitem is a YEARLY or DAILY with no exclusions then it can be stored as aSchedule+ yearly or daily event. Otherwise, it must be fanned.

Referring to FIGS. 27A and 27B, steps 950-984 set out the preferredembodiment of fanning recurring records that must be updated. All casesfall within three scenarios, shown in FIG. 29.

In the first scenario a record which is a Recurring Master, and itscounterpart in the other database is a Recurring Master, must be fannednow for its own database (steps 951-959). If the CIG_TYPE of the recordis 132 (i.e. update both records), then it is changed to 13F which is aspecial value specifically for this situation (step 951). For otherCIG_Types, the CIG is broken into three singleton and given CIG Typessignifying their singleton status. In both of these cases, the functionFanning_For_Add (steps 986-996, described below) is called.

In the second scenario, the record was fanned previously and is going tobe fanned now also. First, the dates of the instances are recorded in atemporary date array (steps 961-963). This array is compared to an arrayof the fanned instances of the recurrence pattern of the CIG RecurringMaster from the other database (steps 965-966). The dates which are notin the array of fanned instance are marked for deletion (step 967). Thedates which are not in the temporary date array should be added to theunloading databases and therefore new FIG records are created for thosedates (steps 968-973). The dates which appear in both arrays arecompared to the Synthetic Master and marked accordingly for UPDATE orLeave_Alone (steps 974-978).

In the third scenario, the record which was previously fanned should nowbe fanned also. The opposing database's record in this scenario is alsofanned instances. This is perhaps the most peculiar of the three cases.For example, a database may be able to handle multi-day (i.e. dailyrecurring) records but not any exclusion dates for such items. Suchdatabase may be synchronized with another database which fans allrecords in the following manner. A record representing a 7-day vacationin the Planner section of the database is fanned out to form 7individual vacation days in the other database. One instance is deletedin the other database. Upon synchronizing the two databases, b/c thefirst databases does not does not provide for exclusion lists, therecord must now be fanned.

In this scenario, Master Records in a CIG are marked as Garbage. Any FIGmembers attached to the H_Record, if any, are also marked as Garbage.All Instances found in the opposing database's FIG are truned tosingleton CIGs with CIG type 100 or 001 so that they will be added tothe unloader's database when unloading is done. In this way theinstances from one database is copied to the database providing forrecurring records.

Steps 985-995 describe the Fanning_For_Add Function which is used whenoutcome is to update or when the function is called by the Translatorfanning for update. For each instance generated by fanning out therecurring record, a clone of the Recurring Master is created butexcluding Rep_Basic and Rep_Excl field values and the unique ID field.All adjustable Date Fields (e.g. Start Date, End Date, and Alarm Date)are set and hash values for the new record is computed. The new recordis then marked as Fanned_For_A or Fanned_For_B, as the case may be. Thisis then attached to the Recurring Master Item as a FIG member.

Following unloading of the B_RECORDS, the Control Module 2 instructs theA Translator to unload the A_Records from the Workspace (FIG. 3, step111). This unloading is done in the same way as it was done by theB_Translator. In case of Rebuild_All Translators which have toreconstruct the database, all records which were loaded from thedatabase but were not used in synchronization are appended and unloadedas the Translator builds a new database for its Application.

The Control Module 3 next instructs the Synchronizer to create a newHistory File (step 112). Referring to FIG. 28, for every CIG in theWorkspace, it is first determined which record should be unloaded toHistory File (steps 1001-1003). In the next step, Excl_Only flag ischecked, which is set by the Merge_Exclusion_List logic (FIG. 21-24). Ifthat flag is set, a new record for unloading is created which has allfields taken from the History File record, except that the newly mergedexclusion list is inserted into that record (step 1004). Before storingthe record in the History File, all Flag Bits in the Extended Index arecleared except the bit that indicating whether or not this is arecurring item (step 1005). The item is marked as a History File recordto indicate its source. The CIG, FIG, and SKG are reset. All the HASHvalues and Start&EndDate&Time will be stored. All applicable unique IDare also stored (Steps 1006-1009). The current record is then stored inthe new History File (step 1010). If the current record is a RecurringMaster for an ID-bearing FIG, we now store the whole FIG (i.e. allFanned Instances) in the History File, with the FIG linkage words set inthe History File to hold the FIG records together (step 1011). Fannedinstances which do not bear unique IDs are not stored in the HistoryFile since they can be re-generated by merely fanning out the RecurringMaster.

Once all records are unloaded, various information necessary foridentifying this History File and for the next synchronization arewritten into the History File (step 1013).

At this point Synchronization is complete.

Applications, such as scheduling Applications, often have more than onedatabase. Each of these databases are known as sections. Each of thesesections contain different data and must be synchronized with theircorresponding sections in other Applications. However, there is notnecessarily a one to one relationship between sections of variousApplications. For example, Application A may comprise of the followingsections: Appointments, Holidays, Business Addresses, PersonalAddresses, and ToDo. Application B however may comprise of the followingsections: Appointments, Addresses, ToDo-Tasks, and ToDo-Calls. Althoughthe general character of the sections are the same, there is not a oneto one relation between the sections of these two Applications:Appointments and Holidays in A contain the same type of data asAppointments in B; Business Addresses and

Personal Addresses in A contain the same type of data as Addresses in B;and ToDo in A contains the same type of data as ToDo-Tasks andToDo-Calls in B. Therefore, when synchronizing the sections of these twoApplications, it is necessary to synchronize at least two sections ofone Application with one section of another Application.

The preferred embodiment performs this type of synchronization byproviding for a number of section categories: Appointment, ToDo, Note,Address, and General Database. All sections of a particular Applicationare studied and categorized according to this categorization. Therefore,in the above example of Application A, Appointments and Holidays arecategorized Appointment type sections (or database), Business Addressand Personal Address as Address type sections, and ToDo as a ToDo typesection.

For creating the map for mapping sections onto each other, an exactsection match is always sought between sections of the two Applications.If not, one of the sections which were categorized as a section type ischosen to be the Main_Section among them. Other sections of the sametype are referred to as subsections. All databases of the same type fromthe other Application will be mapped onto the Main_Section.

To properly synchronize from one time to the next, it is necessary tokeep track of the source of records in the Main_Section. In thepreferred embodiment, if a record in the Main_Section of theA_Application does not come from the Main_Section of the B_Application,one of fields in the record, preferably a text field, is tagged with aunique code identifying the subsection which is the source of therecord. This is the record's Origin Tag. All records in the Workspaceand the History File include a hidden internal field called subTypewhich contains the unique subsection code. Main_Section's field value inthe preferred embodiment is zero so that it will not be tagged. When arecord is loaded from a database into the Synchronization Workspace, thetag is stripped from the TagBearer field and put in the _subType field.If there is no tag, then the _subType is set to be the subtype of thepresent section. If the TagBearer field is mapped then when readingrecords into the Workspace the tag, if any, is stripped from theTagBearer field value place it in _subtype.

Conversely when unloading records from the Workspace to a Database, theTagBearer field is tagged by a tag being added if the record is not fromthe Main_Section.

A Fast Synchronization database is a database which provides a method ofkeeping track of changes, deletions, and additions to its records fromone synchronization to the next. These databases speed up thesynchronization process because only those records which have beenmodified need to be loaded from the database. Since the majority ofrecords loaded by regular Translators are unchanged records, far fewerrecords are loaded from the database into the Synchronizer.

Certain features are required for a database to be a FastSynchronization database. The database records must have unique IDs andmust have a mechanism for keeping track of which records are added,changed, or deleted from synchronization to synchronization, including alist of deleted records. Unique IDs are required to accurately identifyrecords over a period of time.

There are at least two ways to keep track of additions, changes, anddeletions in a database.

First, some databases maintain one Dirty bit per record which is aboolean flag that is set when a record is created or modified and iscleared when a function for clearing Dirty bits is called. Somedatabases offer a Clear DirtyBit function that clears the bit of anindividual record. Other databases offer a ClearDirtyBits function thatclears the Dirty bits of all records in a database. The record-specificClearDirtyBit function allows the preferred embodiment to use thedatabase itself to keep track of additions and changes.

The global ClearDirtyBits function forces the preferred embodiment toclear all Dirty bits at the conclusion of every Synchronization. Then asdatabase edits are made by the user in between synchronizations, theaffected records are marked as Dirty. When Synchronization is performedagain, only the Dirty records are loaded.

Second, some databases maintain a Date&Time stamp of when the record wasadded or last time the record was modified. A Translator for such adatabase finds all records which were added or modified since theprevious synchronization by searching for Date&Time stamps more recentthan the Date&Time of the Last Synchronization.

A Fast Synchronization database must also keep track of deletions. Thisis done by maintaining a list of deleted records which can be read by aTranslator.

A Translator sending Fast Synchronization database records to theSynchronizer provides only records which have been changed, deleted, andadded since the previous synchronization. Therefore, unlike a regulardatabase Translator, a Fast Synchronization Translator does not providethe Synchronizer with unchanged records. Moreover, unlike a regularTranslator it provides deleted records, which the regular Translatorsdoes not.

In order for such databases to be synchronized without resorting totreating them as regular databases, the Synchronizer transforms FastSynchronization records from the Translator into the equivalent regulardatabase records. These transformed records are then used by theSynchronizer in the synchronization. There are two transformations whichare necessary. First, the Synchronizer needs to transform deletedrecords received from the Fast Synchronization Translator into a regulardatabase deletions. Second, synchronization needs to transform lack ofoutput by the Fast Synchronization Translator into unchanged records.

The invention performs these transformations by using the History File.During the first synchronization, all records in the FastSynchronization database are loaded into the history file. As changes,additions, and deletions are made to the Fast Synchronization database,during each of the subsequent synchronizations the same change,additions, and deletions are made to the History File. Therefore, theHistory File at the end of each subsequent synchronization is an exactcopy of the Fast Synchronization database.

When a Fast Synchronization Translator supplies no input for a unique IDH_Record, the Synchronizer finds the corresponding H_Record in theWorkspace and copies it into the Workspace as a record supplied as if itwere loaded by the Fast Synchronization translator itself.

Referring to FIG. 30, steps 1050-1051, the Synchronizer first verifiesthat there is an appropriate History File. Because the FastSynchronizing process relies heavily on the History File, it isimportant to ensure that the same history file as the lastSynchronization is used. Moreover, the History File is the backgroundagainst which the transformation of the Translator outputs into regularTranslator outputs takes place. The History File keeps a date and timestamp of the last synchronization. Each of the Fast Synchronizationdatabase (if able to) and the Fast Synchronization Translator alsostores the same date and time stamp. The time and date stamp is usedbecause it is unlikely that another History File will have exactly thesame time and date entry, for the same two databases. It also identifieswhen last the Fast Synchronizer database and the History File containedthe same records.

At the start of an incremental synchronization, the Synchronizer and theFast Synchronization Translator compare date and time stamps. If timeand date stamp synchronization parameters have changed since theprevious synchronization, then the synchronization proceeds from scratch(step 1052). In a synchronization from scratch all records in the FastSynchronization database are loaded into the History File.

In the preferred embodiment, all records supplied as Fastsynchronization inputs have a special hidden field called _Delta, whichcarries a single-letter value—‘D’ for Delete or ‘A’ for Add and ‘C’ forChange. Records are loaded by the Fast Synchronization Translator intothe Workspace (step 1054). If necessary the records are mapped whenloaded. Records which are marked as changes or additions are sanitizedby the Translator for the other database, but deleted records are notbecause their field values are going to be deleted (step 1055).Orientation analysis (FIG. 11) is performed on the records so that alldeletions and changes to Fast Synchronization database records arejoined with their History File counterparts in unique ID bearing CIGs(step 1107).

All History File records and their CIGs are now examined. If there is nocorresponding record from the Fast synchronization database, it meansthat the record was unchanged. A clone of the record is made, labelledas being from Fast Synchronization database, and joined to theH_Record's CIG. At this point the deleted Fast synchronization databaserecords marked as deletions are removed from CIGs (step 1109). The FastSynchronization records marked as changed are joined in doubleton CIGs.Those marked as additions are singletons. At this point, thesynchronization can proceed as if record of a unique ID bearing regulardatabase were just loaded into the Workspace.

Whenever we are loading from a Fast Synchronization database, allrecords are loaded so that at the end of synchronization the historyfile will be the same as the Fast Synchronization Database. Therefore,referring to FIGS. 31A and 31B, in order to perform date range limitedsynchronization, the invention marks the records which fall outside thecurrent and the previous date ranges. For a record marked as anaddition, or during synchronizing from scratch, if the record fallsoutside the current date range, it is marked as Out_Of_Range (steps 1101and 1153-1154). This record will be written into the History File butnot into the other database or take part in the synchronization. Whenthe Fast Synchronization database records are loaded from the HistoryFile, if they fall outside of the previous date range, they are markedas Bystander (steps 1152-1157). If a Bystander record forms a CIG with aFast Synchronization record marked as a deletion or a change, theBystander is marked with a Garbage flag because its field values serveno useful purpose any more: the record marked as DELETION should bedeleted and the record marked as CHANGED should replace the BystanderH_Record (step 1162).

H_Records for which there are no inputs are transformed in the samemanner as before (steps 1164-1165). If a Bystander record falls withinthe current date range, it is equivalent to a regular database recordcoming into the current date range. Therefore, the H_Record is clonedand marked as a Fast Synchronizer record while the Bystander record ismarked as Garbage (steps 1166-1171). Therefore, just like a new recordof a regular database, it has no H Record counterpart.

If the user selects to abort a synchronization or selects the option toignore a conflict or conflicts in general, some of the records loadedfrom the Fast Synchronization database will not be accepted and recordedin the History File. Therefore, the Translator should provide thatrecord again at the next synchronization. However, because FastSynchronization Translators supply only records which have been changed,deleted, or added since the previous synchronization, the records whichwere not accepted will not be supplied. Therefore, in the invention,Fast Synchronization Translator waits for an acknowledgement from theSynchronizer that the record has been accepted.

In case no such acknowledgement is received for a record, the Translatorneeds to be able to provide that record again to the Synchronizer. Ifthe database allows resetting individual Dirty bits, the Translatormerely does not set that bit. If not, the Translator keeps a separatefile in which it keeps a record of which Fast Synchronization recordswere not accepted. The file may contain the unique IDs of those records.The Translator then uses that file to provide the synchronizer withthose records during the next synchronization.

Other embodiments are within the following claims.

1. A computer implemented method of synchronizing at least a first and asecond database, wherein the manner of storing a set of recurring datebearing instances differs between the first and second databases, and atleast the first database uses a recurring record to store the set ofrecurring date bearing instances, the method comprising: processing aplurality of non-recurring records in the second database to identify aset of non-recurring records storing a set of recurring date bearinginstances in the second database; performing a comparison of the set ofnon-recurring records of the first second database to a recurring recordof the first database; and completing synchronization based on theoutcome of the comparison.
 2. The method of claim 1 wherein the step ofcompleting synchronization includes adding, modifying, or deleting oneof the synthetic set of non-recurring record records and the recurringrecord.
 3. The method of claim 1 further comprising, after completingsynchronization, storing the set of recurring date bearing instances inthe second database as a plurality of non-recurring records.
 4. Themethod of claim 1 further comprising, after completing synchronization,storing the set of recurring date bearing instances in the seconddatabase as a recurring record having a different record structure thanthe recurring record of the first database.
 5. The method of claim 1further comprising storing a history file containing a recordrepresentative of one of the recurring record and the set ofnon-recurring instances records in a past synchronization.
 6. The methodof claim 5 further comprises performing a second comparison of one ofthe synthetic set of non-recurring record records and the recurringrecord to the record in the history file representative of the recurringrecord or the set of non-recurring instances records and completingsynchronization based on the outcome of the second comparison.
 7. Themethod of claim 1 wherein each recurring record and each non-recurringrecord includes a key field, and wherein the step of processing aplurality of non-recurring records in the second database furthercomprises: performing a second comparison of the key fields of therecurring and non-recurring records; and selecting a group of recordsfrom among the recurring and non-recurring records based on the outcomeof the second comparison.
 8. The method of claim 7 wherein the step ofselecting a group of records comprises selecting the group based onidentity of the content of the key fields of the recurring andnon-recurring records.
 9. The method of claim 7 wherein each recurringrecord and each non-recurring record includes at least one other field,and wherein the step of processing a plurality of non-recurring recordsin the second database further comprises: performing a third comparisonof the at least one other field of the non-recurring records in thegroup; selecting a the set of non-recurring records based on the outcomeof the third comparison; and correlating the set of non-recurringrecords to the recurring record of the first database.
 10. The method ofclaim 9 wherein selecting the set of non-recurring records based on theoutcome of the third comparison is based on identity of content of theat least one other field of the non-recurring records in the group. 11.The method of claim 1 wherein processing the plurality of non-recurringrecords further includes processing the plurality of non-recurringrecords to generate a synthetic recurring record representing the set ofrecurring date bearing instances in the second database, and whereinperforming a comparison of the set of non-recurring records to arecurring record includes performing a comparison of the syntheticrecurring record of the second database to the recurring record of thefirst database.
 12. The method of claim 11 wherein, following the stepof completing synchronization, one of the synthetic recurring record andrecurring record is fanned back into a plurality of fanned non-recurringrecords.
 13. The method of claim 11 wherein the synthetic recurringrecord has a list of excluded instances and the step of processing aplurality of non-recurring records in the second database to generate asynthetic recurring record further comprises generating a list ofexcluded instances representative of instances previously represented bythe recurring record and currently represented by another record ordeleted.
 14. The method of claim 11 wherein the recurring record and thesynthetic recurring record each contain a list of excluded date bearinginstances, wherein the step of performing a comparison of the syntheticrecurring record to the recurring record includes performing acomparison of the list of excluded date bearing instances of therecurring record with the list of excluded date bearing instances of thesynthetic recurring record.
 15. The method of claim 14 wherein the stepof completing synchronization includes adding, modifying, or deletingthe list of excluded date bearing instances of one of the recurringrecord and the synthetic recurring record.
 16. The method of claim 14wherein the step of completing synchronization includes adding,modifying, or deleting one of the synthetic recurring record andrecurring record.
 17. The method of claim 14 wherein, following the stepof completing synchronization, one of the synthetic recurring record andrecurring record is fanned into a plurality of fanned non-recurringrecords excluding the instances in the list of excluded date bearinginstances of a corresponding one of the synthetic recurring record andrecurring record.
 18. The method of claim 11 further comprising storinga history file containing a record representative of one of therecurring record and synthetic recurring record in a pastsynchronization.
 19. The method of claim 18 wherein the second databaseassigns a unique ID to each record, and wherein the method furthercomprises: fanning one of the synthetic recurring record and therecurring record into a plurality of fanned non-recurring records;storing records in the history file representative of the plurality offanned non-recurring records; storing in the history file the unique IDsassigned by the second database to the plurality of fanned non-recurringrecords; and recording linkages among the records representative of theplurality of non-recurring records and the record representative of oneof the recurring record and synthetic recurring record.
 20. The methodof claim 18 wherein the second database assigns unique IDs to eachrecord, the history file further contains records representative ofnon-recurring records of the second database from a past synchronizationand unique IDs assigned to the non-recurring records of the seconddatabase, and the step of processing a plurality of non-recurringrecords in the second database to generate a synthetic recurring recordfurther comprises: performing a comparison of the unique IDs stored inthe history file with unique IDs of the plurality of non-recurringrecords in the second database; and selecting a set of non-recurringrecords in the second database based on the comparison of the unique IDsand generating the synthetic recurring record using the set ofnon-recurring records.
 21. The method of claim 20 wherein the step ofselecting a set of non-recurring records further comprises selecting aset of non-recurring records in the second database having unique IDsmatching a set of the unique IDs stored in the history file.
 22. Themethod of claim 20 wherein one of the synthetic recurring record and therecurring record has an exclusion list and the step of selecting the setof non-recurring records comprises: selecting a set of records in thehistory file having unique IDs failing to match any of the unique IDs ofnon-recurring records in the second database; and adding, modifying, ordeleting the exclusion list of at least one of the synthetic recurringrecord and the recurring record, using the set of records in the historyfile.
 23. The method of claim 18 further comprises performing a secondcomparison of one of the synthetic recurring record and the recurringrecord to the history file record representative of the recurring recordor the synthetic recurring record in the past synchronization, andcompleting synchronization based on the outcome of the secondcomparison.
 24. A computer program, resident on a computer readablemedium, for synchronizing at least a first and a second database,wherein the manner of storing a set of recurring date bearing instancesdiffers between the first and second databases, and at least the firstdatabase uses a recurring record to store the set of recurring datebearing instances, comprising instructions for: processing a pluralityof non-recurring records in the second database to identify a set ofnon-recurring records storing the set of recurring date bearinginstances in the second database; performing a comparison of the set ofnon-recurring records of the first second database to a recurring recordof the first database; and completing synchronization based on theoutcome of the comparison.
 25. The computer program of claim 24 whereinthe instruction for completing synchronization includes adding,modifying, or deleting one of the synthetic set of non-recurring recordrecords and the recurring record.
 26. The computer program of claim 24further comprising instructions for, after completing synchronization,storing the set of recurring date bearing instances in the seconddatabase as a plurality of non-recurring records.
 27. The computerprogram of claim 24 further comprising instructions for, aftercompleting synchronization, storing the set of recurring date bearinginstances in the second database as a recurring record having adifferent record structure than the recurring record of the firstdatabase.
 28. The computer program of claim 24 further comprisinginstructions for storing a history file containing a recordrepresentative of one of the recurring record and the set ofnon-recurring instances records in a past synchronization.
 29. Thecomputer program of claim 28 further comprises instructions forperforming a second comparison of one of the synthetic set ofnon-recurring record records and the recurring record to the record inthe history file representative of the recurring record or the set ofnon-recurring instances records and completing synchronization based onthe outcome of the second comparison.
 30. The computer program of claim24 wherein each recurring record and each non-recurring record includesa key field, and wherein the instruction for processing a plurality ofnon-recurring records in the second database further comprisesinstructions for: performing a second comparison of the key fields ofthe recurring and non-recurring records; and selecting a group ofrecords from among the recurring and non-recurring records based on theoutcome of the second comparison.
 31. The computer program of claim 30wherein the instruction for selecting a group of records comprisesinstructions for selecting the group based on identity of the content ofthe key fields of the recurring and non-recurring records.
 32. Thecomputer program of claim 30 wherein each recurring record and eachnon-recurring record includes at least one other field, and wherein theinstruction for processing a plurality of non-recurring records in thesecond database further comprises instruction for: performing a thirdcomparison of the at least one other field of the non-recurring recordsin the group; selecting a the set of non-recurring records based on theoutcome of the third comparison; and correlating the set ofnon-recurring records to the recurring record of the first database. 33.The computer program of claim 32 wherein selecting the set ofnon-recurring records based on the outcome of the third comparison isbased on identity of content of the at least one other field of thenon-recurring records in the group.
 34. The computer program of claim 24wherein processing the plurality of non-recurring records furtherincludes processing the plurality of non-recurring records to generate asynthetic recurring record representing the set of recurring datebearing instances in the second database, and wherein performing acomparison of the set of non-recurring records to a recurring recordincludes performing a comparison of the synthetic recurring record ofthe second database to the recurring record of the first database. 35.The computer program of claim 34 wherein further comprising, followingthe instruction for completing synchronization, instructions for fanningone of the synthetic recurring record and recurring record is fannedback into a plurality of fanned non-recurring records.
 36. The computerprogram of claim 34 wherein the synthetic recurring record has a list ofexcluded instances and the instruction for processing a plurality ofnon-recurring records in the second database to generate a syntheticrecurring record further comprises instructions for generating a list ofexcluded instances representative of instances previously represented bythe recurring record and currently represented by another record ordeleted.
 37. The computer program of claim 34 wherein the recurringrecord and the synthetic recurring record each contain a list ofexcluded date bearing instances, wherein the instruction for performinga comparison of the synthetic recurring record to the recurring recordincludes instructions for performing a comparison of the list ofexcluded date bearing instances of the recurring record with the list ofexcluded date bearing instances of the synthetic recurring record. 38.The computer program of claim 37 wherein the instruction for completingsynchronization includes instructions for adding, modifying, or deletingthe list of excluded date bearing instances of one of the recurringrecord and the synthetic recurring record.
 39. The computer program ofclaim 37 wherein the instruction for completing synchronization includesinstructions for adding, modifying, or deleting one of the syntheticrecurring record and recurring record.
 40. The computer program of claim37 wherein further comprising, following the instruction for completingsynchronization, instructions for fanning one of the synthetic recurringrecord and recurring record is fanned into a plurality of fannednon-recurring records excluding the instances in the list of excludeddate bearing instances of a corresponding one of the synthetic recurringrecord and recurring record.
 41. The computer program of claim 34further comprising instructions for storing a history file containing arecord representative of one of the recurring record and syntheticrecurring record in a past synchronization.
 42. The computer program ofclaim 41 wherein the second database assigns a unique ID to each record,and wherein the computer program further comprises instructions for:fanning one of the synthetic recurring record and the recurring recordinto a plurality of fanned non-recurring records; storing records in thehistory file representative of the plurality of fanned non-recurringrecords; storing in the history file the unique IDs assigned by thesecond database to the plurality of fanned non-recurring records; andrecording linkages among the records representative of the plurality ofnon-recurring records and the record representative of one of therecurring record and synthetic recurring record.
 43. The computerprogram of claim 41 wherein the second database assigns unique IDs toeach record, the history file further contains records representative ofnon-recurring records of the second database from a past synchronizationand unique IDs assigned to the non-recurring records of the seconddatabase, and the instruction for processing a plurality ofnon-recurring records in the second database to generate a syntheticrecurring record further comprises instructions for: performing acomparison of the unique IDs stored in the history file with unique IDsof the plurality of non-recurring records in the second database; andselecting a set of non-recurring records in the second database based onthe comparison of the unique IDs and generating the synthetic recurringrecord using the set of non-recurring records.
 44. The computer programof claim 43 wherein the instruction for selecting a set of non-recurringrecords further comprises instructions for selecting a set ofnon-recurring records in the second database having unique IDs matchinga set of the unique IDs stored in the history file.
 45. The computerprogram of claim 43 wherein one of the synthetic recurring record andthe recurring record has an exclusion list and the instruction forselecting the set of non-recurring records comprises instructions for:selecting a set of records in the history file having unique IDs failingto match any of the unique IDs of non-recurring records in the seconddatabase; and adding, modifying, or deleting the exclusion list of atleast one of the synthetic recurring record and the recurring record,using the set of records in the history file.
 46. The computer programof claim 41 further comprises comprising instructions for performing asecond comparison of one of the synthetic recurring record and therecurring record to the history file record representative of therecurring record or the synthetic recurring record in the pastsynchronization, and completing synchronization based on the outcome ofthe second comparison.
 47. A computer implemented method ofsynchronizing at least a first and a second database, wherein records inthe first and second databases include a key field, the methodcomprising: performing a first comparison of the content of the keyfield of the records of the first database with the content of the keyfield of the records of the second database; selecting a plurality ofgroups of records of the first and second databases based on the outcomeof the first comparison; performing a second comparison of the recordsin one of the plurality of groups of records to determine acorrespondence between a record of the first database in the one of theplurality of groups and a record of the second database in the one ofthe plurality of groups; performing a third comparison of the records inthe determined correspondence; and completing the synchronization basedon the outcome of the third comparison.
 48. The method of claim 47,wherein the method further comprises selecting the plurality of groupsof records based on identity of the contents of the key fields of therecords of the first and second database.
 49. The method of claim 47further comprising storing a history file containing history recordsrepresentative of records of the first and second databases in a pastsynchronization, wherein performing a second comparison includesperforming a comparison of the records in the one of the plurality ofgroups to the history records and wherein performing the thirdcomparison includes comparing a corresponding history record with therecords in the determined correspondence.
 50. The method of claim 49wherein the step of completing synchronization further comprises:performing a third comparison of the records of the corresponding itemgroup; and completing synchronization based on the third comparison. 51.The method of claim 47 wherein the key field is a date field.
 52. Themethod of claim 47 wherein the key field is a text field.
 53. A computerprogram, resident on a computer readable medium, for synchronizing atleast a first and a second database, wherein records in the first andsecond databases include a key field, comprising instructions for:performing a first comparison of the content of the key field of therecords of the first database with the content of the key field of therecords of the second database; selecting a plurality of groups ofrecords of the first and second databases based on the outcome of thefirst comparison; performing a second comparison of the records in oneof the plurality of groups of records to determine a correspondencebetween a record of the first database in the one of the plurality ofgroups and a record of the second database in the one of the pluralityof groups; performing a third comparison of the records in thedetermined correspondence; and completing the synchronization based onthe outcome of the third comparison.
 54. The computer program of claim53, the computer program further comprises instructions for selectingthe plurality of groups of records based on identity of the contents ofthe key fields of the records of the first and second database.
 55. Thecomputer program of claim 53 further comprising instructions for storinga history file containing history records representative of records ofthe first and second databases in a past synchronization, whereinperforming a second comparison includes performing a comparison of therecords in the one of the plurality of groups to the history records andwherein performing the third comparison includes comparing acorresponding history record with the records in the determinedcorrespondence.
 56. The computer program of claim 55 wherein theinstruction for completing synchronization further comprisesinstructions for: performing a third comparison of the records of thecorresponding item group; and completing synchronization based on thethird comparison.
 57. The computer program of claim 53 wherein the keyfield is a date field.
 58. The computer program of claim 53 wherein thekey field is a text field.